home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1160 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.4 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: Roman Lechtchinsky <wolfro@cs.tu-berlin.de>
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Better template syntax?
  5. Date: 18 Apr 1996 21:35:05 GMT
  6. Organization: Technical University of Berlin
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <3176A9E8.555D@cs.tu-berlin.de>
  9. References: <31741E6C.53CA@cs.tu-berlin.de> <317673A9.2EBB@datalytics.com>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. Mime-Version: 1.0
  12. Content-Type: text/plain; charset="us-ascii"
  13. Content-Transfer-Encoding: 7bit
  14. X-Nntp-Posting-Host: 130.149.17.233
  15. X-Mailer: Mozilla 2.0 (Win95; I)
  16. X-Lines: 67
  17. Content-Length: 2390
  18. Originator: clamage@taumet
  19.  
  20. Rob Stewart wrote:
  21. > 
  22. > Roman Lechtchinsky wrote:
  23. > >
  24. > > Hi,
  25. > >
  26. > > sorry for being curious but I'm only human... My question is: when declaring
  27. > > templates, why isn't it required to declare what one expects of the
  28. > > template's parameters? Let's create a template function:
  29. > >
  30. > > template<class T> bool equal( const T& t1, const T& t2 )
  31. > > {
  32. > >   return t1==t2;
  33. > > }
  34. > >
  35. > > Now, personally I would prefer to write something like:
  36. > >
  37. > > template<class T { bool operator==( const T& t ) const; }> ...
  38. > >[...]
  39. > 
  40. > I can't answer whether this has been considered (or rejected),
  41.  
  42. Yes, it has been. I forgot that D&E contains a ( rather short ) discussion on 
  43. this topic. Probably I should have written: "Has there been an attempt to 
  44. define this", a question still unanswered.
  45.  
  46. > but I can see a problem with your proposal.  What if a template
  47. > required ten, fifteen, twenty mfs in its parameterizing type?
  48. > What if those mfs have many parameters?  The resulting list of
  49. > mfs and parameters would become quite ungainly.
  50.  
  51. Actually, when I define a template I usually describe what it expects from 
  52. its parameters in a comment. This means I have to write this list anyway. Do 
  53. other programmers do it?
  54.  
  55.  
  56. > Perhaps you could declare a class with the exact interface you
  57. > expect and provide that as a model for the parameterizing type?
  58. > This still leaves issues like equivalence.  Are implicit
  59. > conversion allowed in mfs of a parameterizing type in order to
  60. > match the model?  At what point do you decide there is no match?
  61.  
  62. I'm currently trying to define how this can be handled. In general, I think 
  63. the following would do: a function matches a function required by the 
  64. template if
  65. a) its return type can be implicitly converted to the required return type 
  66. and
  67. b) the types of its parameters can be implicitly converted to the types of 
  68. the correspondenting required parameters.
  69. I wonder if someone has already tried this and what the results are.
  70.  
  71. > 
  72. > What about the template code?  What if it you misuse the
  73. > parameterizing type relative to your model?  Is the model wrong
  74. > or is your code wrong?
  75. > 
  76.  
  77. I'm not sure what you mean here.
  78.  
  79. > There's probably a lot more I haven't thought of yet. 
  80. Yes, definitely. However, there's probably a lot more that hasn't been 
  81. thought of ( or that is being thought of a this very moment ;-) about 
  82. templates as well.
  83.  
  84. Bye
  85.  
  86. Roman
  87.  
  88.  
  89. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  90. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  91. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  92. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  93. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  94.